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ABSTRACT ^ 

This paper will define the framework of a general method for selecting a necessary and sufficient subset of a general 
software life cycle's information products, to support new software development projects. Procedures for character- 
izing problem domains in general and mapping to a tailored set of life cycle processes and products will be given. An 
overview of the method is shown using the following steps: 

1. During the problem concept definition phase, perform standardized interviews and dialogs between devel- 
oper and user, and between developer and customer. 

2. Generate a quality needs profile of the software to be developed, based on information gathered in step 1. 

3. Translate the quality needs profile into a profile of quality criteria that must be met by the software to satisfy 
the quality needs. 

4. Map the quality criteria to a set of accepted processes and products for achieving each criterion. 

i. Select the information products which match or support the accepted processes and product of step 4. 

6. Select the design methodology which produces the information products selected in step 5. 

This paper will address every step, but will not attempt to generate a full-up methodology. A few of the more popular 
process models and design methodologies known today will be examined for their information content. 


TERMINOLOGY NOTES 

The terms "software process model" and "life cycle" will be used interchangeably. The term "user" will always mean 
"customer and user". 


INTRODUCTION 

The complete set of information products defined for common software process models and development method- 
ologies is often too large fbr certain development efforts. In many cases, a subset of informauon products and the 
activities that produce them will suffice to administer the development of a software product. The act of selecting 
appropriate information products and activiues to support the development effort is called "tailoring" the life cycle 
or development methodology. This tailoring process is currently an ad hoc method performed by managers and 
developers, in early meetings with the customer and user, as they begin to define some sort of Software Management 
or Development Plan. This paper explores a more formalized tailoring method to assist in the definition of such 
plans. It is hoped that such a formalization will both speed the process and help ensure the selection of a necessary 
and sufficient subset of information products (and by implicauon. the acuvtues which produce them). 

The cornerstone of this tailoring method uses Software Quality Assurance (SQA) techniques. Traditionally. SQA 
has dealt with the detection and prevention of defecuve software. New ideas in the field of SQA are concentraung on 
beginning the function much earlier in the life cycle, as early as problem concept and initial requirements definition 
It is hoped that SQA principles will assist the user and developer in creating complete, consistent and testable 
require n^ents^This assistance offers guidelines up front when we're scrambling to put some sensible words on paper 
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1 believe that two quotes [5], (21) can illustrate the idea of ’engineering in* quality to a software product. 


You can’t achieve Quality... 
unless you specify it! 


Quality must be defined as conformance 
to requirements, not as ’’goodness” 


USING SQA TECHNIQUES TO SPECIFY QUALITY 


Quality Factors 

This is a common SQA term. Quality Factors are characteristics which a software product exhibits that reflect the 
degree of acceptability of the product to the user. Since we’re moving SQA up front, we'll restate this: Quality 
Factors are characteristics which the user requires the software to exhibit in order to reflect the best possible degree 
of acceptability. 

Table 1 shows a list of Quality Factors which has been coming into general use for some time [21]. It was first 
proposed at the Rome Air Development Center (RADC) in 1977. I show a slightly expanded list, as it has evolved 
somewhat since then [5]. 

There are more detailed meanings of the quality factors which guide the user developer in determining how 
important each factor is for their application. 

Not every project requires all quality factors, which is good, because some quality factors are at conflicting purpose. 
Shown below is a list of factors whose characteristics cause conflicts of definition. 

quality Factor Conflict Ewianaticn oL QOnDiCL 

Efficiency vs. Integrity Overhead required to control access negates efficiency. 

Efficiency vs. Usability Overhead required to ease operations negates efficiency. 

Efficiency vs. Maintainability— Optimized code negates maintainability. Modularization, instrumentation 

and well commented high-level code increases overhead. 

Efficiency vs. Testability Optimized code negates testability. 

Efficiency vs. Portability Optimized code is dependent on host processor services. 

Efficiency vs. Flexibility Overhead required to support flexibility negates efficiency. 

Efficiency vs. Reusability ■ — O verhead required to support reusability negates efficiency. 

Efficiency vs Interoperability— Overhead required to support interoperability negates efficiency. 

Integrity vs. Flexibility Flexibility requires general ana flexible data structures, increasing data 

security problems. 

Integrity vs. Reusability — Generality required by reusable software introduces protection problems. 
Integrity vs. Interoperability Coupled systems allow more avenues of access. 

Reusability vs. Reliability — Generality required by reusable software increases difficulty of providing 

error tolerance (anomaly management) and accuracy. 

The conflicts shown do not mean that the two factors are in strict mutual exclusion — extra effort may be expended 
to address the difficulties of specifying factors in conflict. Note that efficiency tends to conflict with many other 
factors. This is due to the tradeoff with the additional overhead required to satisfy other quality factors that does not 
necessarily apply tc the algorithm's basic function. Efficiency issues may also be resolved by judicious hardware 
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Correctness 

— Conformance of software design and implementation to stated require- 
ments. 

Efficiency 

— Economy of resources needed to provide the required functionality. 

Expandability 

— Ease of maintaining the software to meet new functional or performance 
requirements. 

Flexibility 

— Ease of maintaining the software to work in environments other than 
originally required. 

Integrity — 

— Security against unauthorized access to programs and data. 

Interoperability 

— Ease of coupling the software w\th software in other systems or applica- 
tions. 

Maintainability 

— Ease of finding and fixing errors. 

Manageability 

— Ease of administrating development, maintenance and operation of the 
software. 

Portability* 

— Ease of maintaining the software * > execute on a processor or operating 
system other than that originally required. 

Usability— 

— Ease of learning <St using the software, and of preparing input & interpret- 
ing output. 

Reliability 

— The rate of failures in the software that render it unusable. 

Reusability 

— Suitability of software modules for use in other applications. 

Safety 

— Protection against loss of life or liability or damage to property. 

Survivability 

— Continuity of reliable execution in the presence of a system failure. 

Verifiability (testability) 

— Ease of verification of functionality against requirements. 


Table 1 - Quality Factors 

selection. Note that there is also a reverse-i.iatrix of quality factors (not shown) that tend to suppon one another, 
such as testability and maintainability — similar *sts of criteria suppon both factors. 

So you get the idea of defining quality needs for specific applications. As this process of definition continues, a 
profile begins to emerge that descnbes the proposed software in terms of weighted quality factors. 


I introduce this term to describe the prioritized, weighted list of quality factors that the user Sl developer define for 
their software development effon. The Quality Profile is a "signature" or "fingerprint" of a project’s quality needs. 
Humphrey [10) offers a common-sense example of what kinds of factors are important for different applications, 
based upon the "primary concern" of the application. 




iddfridivM.es* 



a. 

Effect on human lives 

Reliability. Correctness. Testability 


b. 

Long life Cycle 

Maintainability, Flexibility, Portability 

r 

i 

c. 

Real time application 

Efficiency, Reliability. Correctness 

* 

d. 

In-house tool 

Efficiency. Reliability. Correctness 


e. 

Classified Informauon 

Integrity 


f. 

Communicating systems 

Interoperability 


The High Pnomy Quality Factors shown for each type of application begin to define that application's quality profile. 
The profile of an applicauon of type "a" is given by high degrees of reliability, correctness and test abdd y . zr.d io*er 
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degrees of the remaining factors. In practice, we define a more precise scale of degrees and assign a particulars' ;h* 
to each factor. The resultant set of quality factor weights defines the quality profile for the proposed soft*-, re. 

Another example, more generic, is given by Deutsch [5] to suggest an initial prioritization of Quality Factor oy 
"software category”. 


a. 

Critical 

Safety, Survivability, Correctness, Maintainability, Efficiency 


b. 

Support 

Maintainability, Verifiability, Interoperability, Portability, Usability, Correctness 

* 

c. 

I/O 

Correctness, Interoperability, Maintainability 


d. 

Data 

Interoperability, Portability, Reusability 


e. 

Computational 

Correctness. Maintainability 

~ 

f. 

Environment 

Maintainability, Verifiability, Correctness, Interoperability. Portability, Reusabil- 
ity, Efficiency, Integrity 

• 

g- 

MMI 

Integrity, Usability 


h. 

Documentation 

Correctness, Maintainability 

• 

i. 

Design 

Expandability, Flexibility, Interoperability, Maintainability. Portability, Reusabil- 
ity, Verifiability 

•* 


These two examples offer 
multiple concerns or cover 
specific application. 


starting points for the development of a Quality Profile. Many applicatx>ns will exhibit 
several categories. It is the job of the user <fc developer to define the Quality Profile for the 


Deutsch [5] suggests a metric for ranking or weighting quality factors. 

Lev* l nf quality required _ Whtu techniques should be used 10 ensure a quality factor of this mnk 
E Excellent Exceptional techniques 

G Good Better than average techniques 

A Average Normal corporate practices 

NI Not an Issue No special techniques 

He then extends the metric into the realm of cost and schedule prediction, using Jensen and COCOMO modes 
relative cost and relative schedule analysis factors. Cost and schedule prediction will not be pursued further here. 

Latter day SQA is also developing standardized means by which the user and developer discuss and come -:a 
agreement of these factors for each application. These means often take the form of questionnaires that promp. 
user to evaluate all needs for quality. 


This is a common SQA term. Quality Criteria are detailed subcharacteristics which the software exhibits that reflect 
the degree to which the Quality Factors are present. In other words, the planned presence of high— level qualirr 
factors implies the presence of a detailed set of quality criteria. 

The Quality Factors are user-oriented; they are designed to map easily to a user's needs for the proposed software, 
The Quality Criteria are more software-oriented; they are designed to map easily to characteristics that may be 
evaluated by direct testing of the software. The relationship between quality factors and quality criteria is analogous 
to that between the two common stages of requirements definition. The analogy does not apply to the amount of 
effort needed to go from the early phase to the later — Quality Factors may be translated immediately to Quality 
Criteria. Table 2 shows a list of Quality Criteria [5], [21]. 


There is a direct translation from each Quality Factor to a subset of Quality Criteria which support the factor. The 
sets of criteria that support different factors ’iy be disjoint or may intersect. Some criteria exhibit conflicts similar to 
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Quality Criterion _ Ktoanlnw nf tritrrian in cnnttxt of software nrnduct 

Accuracy Achievement of required precision in calculations and outputs 

Anomaly Mgrat Behavior for recovery from failures 

Augmenttbility Maintenance effort required to expand upon functions and data 

Autonomy —Degree of decoupling from execution environment 

Commonality — —Use of standards to match "look and feel" of similar applications 

Communicativeness- Appropriateness of inputs and outputs 

Completeness Degree to which all software is necessary and sufficient 

Conciseness Amount of code used to implement algorithm 

Consistency Use of standards to achieve uniformity within software 

Distributivity Physical (device) separation of function and data (addresses backup) 

Document Quality Access to complete, understandable information 

Communication Efficiency-Usage of communication resources 

Processing Efficiency Usage of processing resources 

Storage Efficiency Usage of storage resources 

Functional Scope Range of applicability of software product's functions 

Generality Range of applicability of software’s internal units 

Independence Degree of decoupling from support environment 

Instrumentation Amount of code devoted to usage measurement or error identification 

Modularity Cohesion Coupling of software’s modules (design & code) 

Operability Ease of operating the software 

Safety Management Degree to which the design addresses hazard avoidance 

Self-Descriptiveness- Undentandabiiity of design & code 

Simplicity ——— Degree to which algorithms map to the problem they solve 

Support —Functionality that addresses the administration of maintenance 

System Accessibility- C ontrolled, access to functions, data and instructions 

System Compatibility Use of standards to match interfaces with hardware Sc communications 

Traceability Ease of finding links between requirements, design and code 

Training Provisions to help users leam the operation of the software 

Virtuality Separation of logical implementation from physical component 

Visibility Objectivity of evidence of correct functioning — ease of test verification 


Table 2 - Quality Criteria 


those examined for quality factors. Table 3 shows a translation between Quality Factors and Quality Cntena that 
shows how the criteria support and influence the factors, either positively or negatively. The traditional direction ot 
translation is from criteria to factor — the SQA or test team measures the criteria from the software, and reports on 
what quality factors the software thus exhibits. Our method will begin with the user definition of quality factors, and 
develop a set of criteria that the software must meet in order to satisfy our quality needs. 

This table is merged from two different authors’ approach to the factor/criteria map [S], [21]. Their perspecuves 
overlap to a high degree, but each one shows a few more, different criteria than the other. I have included them ail 
here in order to work with the most complete universe of factors and criteria possible. Detailed examination of the 
authors’ text reveals that while some factors and criteria sound very similar, they actually do describe different 
characteristics of the software. 
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Quality Factors 
Quality Criteria 
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Table 3 - Quality Factors <=> Quality Criteria Map 


Symbols are used in the cells of the matrix in Table 3 to indicate the influence a criterion has on various factors. 
Another viewpoint is that they indicate which criteria are necessary to support each factor. A plus under a factor 
means that the software should be required to exhibit the corresponding cnterion, but is subject to trade-off based 
on any conflicts that arise. A double plus means that the criterion is more important, and less subject to trade-off. A 
negative under a factor means that it would be wise not to require the software to exhibit the corresponding cnterion. 
but is subject to trade-off based on the influence of other factors. A double negative means that extra effort must be 
expended to require the software to exhibit the corresponding criterion. 
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The assignment of pluses and minuses is a subjective process* but the concept has been refined over time by varaxa 
authors [5], [8], [10], [21]. 


SOFTWARE PROCESS MODELS 

"The software process is the technical and management framework established for applying tools, methods and 
people to the software task” [10]. 

There are a handful of well-defined "process models" or "life-cycles" in the industry today. They each describe a 
set of activities and products designed to support the successful creation of a software product. The most widely used 
model is called the Waterfall model. Other models are coming into use that attempt to address the shortcomings of 
the Waterfall, but they tend to generate very similar information products. Appendix D offers a brief description of 
other common process models. 

The Waterfall model is characterized by a linear set of activities and products such that each acuvity uses the output 
of previous activities as its input. Here we list general names of the primary technical products of a waterfall mocel. 

Activity ( phase) Maiou2caduct: generated by acmiiy tehasc.) 

Concept Definition Feasibility Study, Concept document 

User Req. Definition Level-A Requirements Document, Software Management Plan. System Interface 

Control Document (ICD) 

System Req. Definition Level- B Requirements Document, Subsystem ICDs 

System Design System Design Document. System Test Plan 

Implementation Software, Test Case Document 

Testing Test Report 

Maintenance Upgraded Software, Maintenance Report 

Note that the waterfall model itself does not really define details of the information products that are to be producid. 
Most users of the waterfall model recommend a larger set of documentauon; these recommendations are usually laid 
out in a documentation standard. 

SOFTWARE DOCUMENTATION STANDARDS 

A Documentation Standard defines all information products that may be generated to support development of me 
software product. Usually, a documentation standard is packaged with a life-cycle standard. Two common scandanis 
are: 

SMAP Information System Life Cycle & Documentation Standards [15] 

DOD-STD-2167A [6] 

For this study, we will use the document set defined by NASA’s Information System Life Cycle Documentation 
Standard — Appendix A shows the complete list. Our tailoring method will address which of these products are 
most important for a given set of quality factors. 

ANALYSIS & DESIGN METHODOLOGIES 

Within the framework of the software process model, some method must be used to define the content of each 
product. Formalized methodologies address the complex definition of the requirements and design products of the 
software process. There are many different methodologies to choose from for use within any software process. The 
information content of the requirements document, then, may vary according to the technique used to produce .t. 

For example, one may choose to specify system requirements using: 
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a. a simple textual notation developed in an ad hoc manner, or from lessons learned during prototyping. 

b. a functional decomposition hierarchy of diagrams, capturing the requirements in processes and data flows. 

c. an information model, capturing the requirements in objects, relations and behavior diagrams. 

d. a viewpoint/behavior model, capcuring requirements in data/action maps and state diagrams. 

e. a hybrid of the above techniques, or other techniques. 

Appendix C gives a brief overview of some of the more popular methodologies in use today, and lists all the specific 
products they offer. Our tailoring method may eventually be used to select a meaningful subset of these products; the 
current version of the paper will not explore this. 


TAILORING INFORMATION PRODUCTS 

The hierarchy of S MAP- recommended information products for the software development effort is shown in 
Figure 1. 


Software Process Model 


Concept Phase 
-Activities 

-Information Products 


Requirements Phase 
-Activities 

-Information Products 


-Management plan 
-Acquisition plan 
-RFP 
-WBS 

-Dev. contract 
-Config Mgmt plan 
-Risk mgmt plan 
-Assurance plan 
-Concept spec 
-Assurance specs 
-Lessons learned doc 
-Assurance reports 
-Phase transition re- 
view reports 


•Development plan 
■Test plan 
■I V«fcV plan 
•SE&O plan 
•Requirements spec 
•Interfaces 
■User's guide 
■Acceptance test doc 
•Discrepancy reports 
-Eng. change proposals 


Design Phase 
-Activities 

-Information Products 

-Eng <fc Integ plan 
-Support plan 
-Architectural spec 
-Detailed spec - 
-Integration test ___ 
-Prototyping reports 


Implementation Phase 
-Activities 

-Information Products 

-Software components 
-Maintenance manual 
-Unit test document 
-Unit test reports 
^-Customer inspect report 



It is the content of these documents that is addressed by the various 
software development methodologies. The tailoring method will also 
address recommendations for the contents of these documents. 


Figure I - SMAP Information Product Overview 

Each Information Pn>:;uct shown will be analyzed to determine which quality criteria it best supports. The same 
analysis will be applied to the information products generated by various development methodologies. At this point, 
we will be ready to translate a set of 15 user defined Quality Factors sr.:o a recommended set of iniermation prod- 
ucts. 

Tailoring will proceed on three levels: 

1. A subset of the document universe will be selected for the specific quality profile. Example: recommend 
producing a Software Recuu-ements Spec, among other documents. 

2. For each selected information product, a subset of it’s maximum table of contents will be selected. Example: 
recommend defining a Data Definition section in the Software Requirements Spec, among other secuons. 

3. For each recommendation from the table of contents, a set of suggestions will be given to characterize the 
nature of the information that should appear therein. Example: make the following recommendations for 
the contents of the Data Definition section: minimize the number of different data representations, mini- 
mize number of data conversions, use dynamic memory allocation, pack all data items, etc. 

The user/developer then examine the lists of recommendations, and decide whether they make sense in the context 
of the project. There may still be some manual tailoring to do, but the bulk of the job will have been performed by 
this method. 
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FUTURE WORK 

The length of this study was not great enough to develop the full translation from Quality Criteria to Information 
Products. As a starting point* the requirements volume contents in Appendix B have been mapped to quality crite- 
ria. Areas that need more work are: 

1 . Develop the complete translation between Quality Criteria and all information products listed in the Appen- 
dices. This will include not only the selection of specific products, but recommendations for the character od 
that product's content. 

2. Extend the tailoring method to include the tailoring of Management and Assurance activity products, as wedl 
as technical development products. 

3. Define a weighting scheme for ranking Quality Factors that is consistent with Software Process Model and 
Design Methodology characteristics. 

4. Analyze the list of information products generated by the outstanding process models in use today, and 
annotate with descriptions of the information content of each product. These descriptions should be com- 
patible with the weighting scheme defined in area 3. 


Appendix A 

LIFE CYCLE PHASES & INFORMATION PRODUCTS: 

NASA’S SOFTWARE ACQUISITION STANDARD 

This appendix lists the life cycle phases and information products for NASA's Software Acquisition Life Cycle is 
defined by the agency's Software Management and Assurance Program (SMAP). This set of documentation wall 
serve as the universe from which a tailored set will be extracted. 

The SMAP plan for volume roll-cut describes a mechanism which allows the manager/developer to create informa- 
tion products as sections of one volume, or as separate individual volumes, or as a combination, depending upon t ne 
required complexity and management of the particular information product. The tailoring method will select a subset 
of these information products by recommending the "complexity" of each information product. It is recognized that 
there are considerations for tailoring other than the quality profile* especially as apply to the Management Plan- 
Initial tailoring guidelines will focus on the Product Specification, then the Assurance Specification. 

Life Cycle Phases 

Concept Definition Phase (CD) 


Requirements Definition Phase (Req): User requirements. System Requirements 
Design Phase: Software Architectural Design (SAD), Software Detailed Design (SDD) 
Implementation Phase. (Imp!) 

Integration and Test Phase: Integration <& Unit Test (I AT). Acceptance Test (AT) 
Maintenance, or Sustaining Engineering & Operations (SE&O) 

Information Products: Data Item Descriotions (DID) 

inrludinf updater 

Management Activity Products: the Management Plan 

Product 

Phase fs) durint which product is generated. 

Comnonent Management Plan 

CD I AT 

SFAO 

Component Acquisition Plan 

CD 


Request for Proposal 

CD 


Work Breakdown Structure 

CD 


Software Develonment Contract 

CD 
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Appendix B 

INFORMATION CONTENT of the NASA-SMAP STAN* 

DARD SOFTWARE PRODUCT SPECIFICATION 

( This appendix lists the full table of contents for SMAP's Software Product Specification (SM AP-DfD-POOO-SW) . 
This document package contains a Software Concept Document, a Software Requirements Spec, a Software Archi- 
t tectural Design Spec, a Software Detailed Design Spec, a delivery Version Description, a User's Manual and a 

Maintenance Manual, (from [ 15]) . The contents have been extended to include a more complete list of information 
items that may be useful (from [1]). The extended items are italicized. 

An initial pass at mapping document sections to quality criteria has been performed for the Requirements Volume — 
the map uses abbreviations shown in the key below, and should be read "backwards" for each criterion. In other 
words, the map is to be used by selecting those document sections that show a reference to each criterion that is 
l specified by the quality profile. 


Ac: 

Accuracy 

DQ: 

Document Quality 

Sf: 

Safety Management 

AM: 

Anomaly Mgmt 

EC: 

Communication Efficiency 

Sd: 

Self-descriptive ness 

Ag: 

Augmentability 

EP: 

Processing Efficiency 

Sm: 

Simplicity 

At: 

Autonomy 

ES: 

Storage Efficiency 

Sp: 

Support 

Cm: 

Commonality 

FS: 

Functional Scope 

SA: 

System Accessibility 

Cc: 

Communicativeness 

Gn: 

Generality 

SC: 

System Compatibility 

Cp: 

Completeness 

Ip: 

Independence 

Tc: 

Traceability 

Cn: 

Conciseness 

Is: 

Instrumentation 

Tr 

Training 

Cs: 

Consistency 

Md: 

Modularity 

Vn 

Virtuality 

Ds: 

Distributivity 

Op: 

Operability 

Vs: 

Visibility 


Key: Quality Criteria Abbreviations 


The Introduction and Related Documentation sections are recommended in their entirety for every software devel- 
opment effort. Content of the volumes following will be addressed by the tailoring method. (At present, only the 
Requirements Volume is addressed). 


; Introduction 
i Identification of Volume 

Scope of Volume 

. Purpose and Objectives of Volume 

j Volume Status and Schedule 

Volume Organization and Roll-Out 

Related Documentation 
Parent Documents 
Applicable Documents 
Information Documents 

<* 

| Concept Volume 

Definition of Software 
Purpose and Scope 
Goals and Objectives 
Description 
Policies 

[ ' Anticipated Uses of System 

’ Optional Configurations 

User Definition 


r 
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Overview of tha User Organization 
Logical organization 
Physical organization 
Temporal organization 
reporting cycles 
scheduled events 
Information flow organization 
Capabilities and Characteristics 
Sample Operational Scenarios 
Anticipated Operational Strategy 
System ownership 
System administration 
operational control 
modification policy 
change support 
User administration 
departments 
skill level : 

Funding stre^z jy 
Currently Used Procedures 

Requirements Volume 

Requirements Approach and Tradeoffs 

Design Standards to be used 

World Model (Information model) type A 

Entity- Re lot ion summary (Data Requirements) 

Entities: description . attributes . class size 
Attributes: description . values . defaults, constraints . 

class size, retention! archive requirements 
Relationships: description, size, components, constraints 
Individuals (instantiations of entities) 

World Model (Information model) type B — 

Objects: description . allowed operations ^ class size 
Allowed Operations: constructors , interrogators , 
iterators, etc . 

Messages: sent, received 
External Interface Requirements -™ - - ■ 

Operational Resources A Resource Limitations 
Requirements Specification 

Process and Data Requirements 

Function Input data A Source 

Function Transactions and Algorithms - 

Function Output data <fc Destination 

Function Triggering mechanisms A conditions 
Function Termination mechanisms A conditions 

Function Expected demand 

Data Definition - 

Data Relationships 

Data Protection requirements 

Data Validity check requirements 

Data Parameterization requirements 

Data Format or Implementation Restrictions 
System Behavior Requirements 
Phases A Modes 
System Actions 


DQ, Tc 

Cm, Cs, Md, SC 
Ag. Cc, Md. Sd. Vr 


Ag. Cc, Md. Sd. Vr 


-Cc, EC. SC 
-EC, EP. ES. Vr 


-Ac, Ag, AM, Cc. Cm, Gn. SC. Sd, Tc. V$ 
-Ac. Ag, AM, Cp, Cs, EP, FS, Gn. Md 
-Ac, Ag. AM, Cc. Cm, Gn, SC. Sd. Tc, Vs 
-AM. Cm. EP 
-AM. Cm. EP 
-EP 

-Ac, Ag. At 
-Ac, Ag, At 
-Op 

-Ac. AM. Gn, Ip. Op. SA 
-Ac, Ag. Gn, Sd. Vr 
-Ac. Ag. At 

-Ac. .Ag. AM. SI 
-Ag. AM. Cm. Sf 
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Performance and Quality Engineering Requirements 
Timing & Sizing requirements- 


Sequencing <fc event timing requirements- 
Throughput <fe capacity require ments- 


-EC, EP, ES 
-EC, EP 
-EC. EP 


Error Detection, Isolation, Recovery requirements — Ac, AM, Ds, Is, Sf 


Quality Engineering require ments- 
Quaiity factors required 
Safety Requirements 
Security and Privacy Requirements 
Access requirements 

to functions 

to data 

to code 


Legal requirements - 
Audit requirements - 


Other policy-based requirements 

Implementation Constraints 

Site Adaptation 

Design Goals 

Human Factors Requirements 
User type definition 

level of computer sophistication- 
technical competence required — 
Physical constraints 
response time- 


special physical limitations! requirements- 

On-line help requirements 

Robustness requirements 

Failure message <fc diagnostic requirements — 
fnputlOutput convenience requirements 
defaults 
formats 

Traceability to Parent's Design 

Partitioning for Phased Delivery — — 


-ALL 


-AM, Sf. SA 


-Cm, Sf, SA 
-Cm, Sf, SA 
-Sf. SA 
-Sf 
-Vs 

-Ag, Ds, Ip 
-Ag, At, Gn 
-Cn, Co, Gn, Sm 


-Op, Cc 
-Op. Cc 


-Cm, Op 
-Cm. Op 
-Op 

-AM. Gn. Sf. SA 
-AM, Cm, Cc, Gn, Is, Op 
-Cm, Cc. Is. Op 


-Tc, Sm 
-DQ. Tc, Vs 


Design Volume 

Architectural Design 

Design Approach and Tradeoffs 
Architectural Design Description 
External Interface Design 
Requirements Allocation and Traceability 
Partitioning for Incremental Development 
Deoiled Design 

Detailed Design Approach and Tradeoffs 
Detailed Design Description 
External Interface Detailed Design 
Coding and Implementation Notes 
Firmware Support Manual 


Version Description Volume 
Product Description 
Inventory and Product 
Materials Released 
Product Content 
Change Status 

Installed Changes 
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Waivers 

Possible Problems and Known Errors 

User Documentation Volume 
User’s Guide 

Overview of Purpose and Function 
installation and Initialization 
Startup and Termination 
Functions and their Operation 
Error and Warning Messages 
Recovery Steps 
User’s Training Materials 

Maintenance Manual Volume 
Implementation Details 
Modification Aids 
Code Adaptation 
Standards 

Abbreviations and Acronyv-i 

Glossary 

Notes 

Appendices 


Appendix C 

DESIGN METHODOLOGIES and their INFORMA- 
TION PRODUCTS 

“Hus appendix lists information products generated by the more popular analysis k design methodologies of the day 
(compiled from (3], (9]). These products make up a portion of the contents of the Software Product Spec as listed in 
Appendix A and Appendix B. It is hoped to extend the tailoring method to recommend an appropriate set of design 
methodology information products based cn the quality profile. 

Functional Decomposition 

Structured Desig n fSP) — Constantine/Mvers/Yourdon 

This is the traditional data flow diagram methodology that has been in use since the early seventies. It’s main 
products are a hierarchical set of data flow diagrams, process specifications and a data dictionary. State transi- 
tion diagrams may also be used when deemed i\ pessary by the analyst. 

Real Time Structured Aasluil & Design (RTS ADI 

This methodology is similar to SD. but includes the analysis and design of coxxrol flow between processes. State 
transition diagrams, decision tables and process activation tables are used with more regularity. 

Qbiect Oriented Deaim rOODt 

OOP — Booch 

The objects defined in Booch's OOD have associated attributes and allowed operations. They use the concepts 
of visibility, class and inheritance, and they communicate with each other via message passing. One of Booch’s 
goals in designing this methodology was to be compatible with the Ada language, and the objects map well to Ada 
constructs. 

GOOD (General OOP) — Seidewitr 

The objects defined in this OOD have associated aitnbutes only. They are ved to one another not by message 
passing, but by defined relationships. This is an attempt to model the real world more closely, and applies well to 
non-^al time application*,. 


14 


M. A rend 

McDonndl Douglas 
Page 14 of 31 



A Method for Tailoring thm Information Contant of a Software Procaaa Modal 


Oth*r Methodologies 


J»rksnn Structured Dftrign ( TSDl — Jackin 

This unique approach was an early contender on the requirements modeling scene, and is still going strong. As 
industry has developed the terms, we discover that JSD is a natural hybrid of Object Oriented and Functional 
Decomposition methodologies. JSD has its own set of information products which do not match 100% any of the 
traditional products in the map below, but I show what traditional products are most like those produced by JSD. 
rather than specifying and defining new product categories. 

Ada-based Design Annroach for Real Tim* Sv stems TAP ARTS) — Gflmit 

This methodology is an Ada-based version of DARTS; it builds upon the SCR module structuring criteria, the 
Booch object structuring criteria, and the DARTS task structuring criteria to generate maintainable and reusable 
software components. It offers consideration of the concurrent nature of real-time systems. The analysis and 
design diagrams use the "Booch-gram" Ada notation. 

Software_ Cost Reduction (SCR1 — Pam as 


This real-time oriented methodology concentrates on the modules that will make up the software product, an 
information-hiding hierarchy into which they fall, and the interfaces which they use among themselves. Without 
trying, it is almost object oriented. The methodology offers strong support for software reuse. 

Software Product ivity CQnsortium_MethQdQlQrv_fSPCMl_— Comma 

This methodology is based on SCR. Its primary areas of focus are the inclusion of rapid prototyping techniques 
and the production of reusable software. 

Informati on Products of the Methodologies 


Froduct 

Context Diagram 



SD 

gQlQtlCS. 

Rtsad 

xtmcfLi 

iBWrt..icncra:it 

m of product 


Data Flow Diamrru 

so 

Rtsad 


GOOD JSD 

Adam 


Control Flow Diagrams 

SD 

Rtsad 





Control Transformations (State Transitions! SD 

Rtsad 

OOD 

GOOD JSD 

Adarts SCR 

SPCM 

Mini-Specs 

SD___ 

Rtsad 





Data Dictionary _ 

SD 

Rtsad 


JSD 



Structure Cham 

SP_ 

Rtsad 


JSD 

Adam 


Hardware Diagram 



OOD 




ria« Stnicture Diagram 



OOD 




Architecture Diagram 



OOD 




Ada Package Soecs 



OOD 




Object Diagram 



OOD 

GOOD JSD 



Fntitv- Relation Diagrams 


Rtsad 


GOOD 



Process Definition. 




GOOD 


SPCM 

Object Composition 




..GOOD 



Qbiect DescriotioM 




GOOD 



Task Structure Soecs 





Adarts SCR 

SPCM 

Module Guide 





_ Adarts SCR 

SPCM 

Module Interface Specs 



OOD 

GOOD 

Adam SCR 

SPCM 

“Uses* Structure 





Adam SCR 

SPCM 

Module Internal Design Spec 





SCR 

SPCM 

Snhset Spec 





SQL 

SPCM 


Appendix D 

OTHER SOFTWARE PROCESS MODELS 

A sampling of Software Process Models other than the Waterfall Model are briefly described here. Recall that their 
associated information products are very similar to those described in Appendix A. 
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Spiral 

A management oriented model. Activities and products are almost identical to those of the waterfall model, but are 
interspersed with regular prototyping and risk analyses efforts to guide the process. 

Tfopiri Pmtn typing 

This prototyping model coven the requirements definition phases of the waterfall or other similar model. It is gener- 
ally recommended for never-before-attempted solutions, or when the user & developer deem areas of the problem 
concept to be technologically difficult. 

A partial implementation of the system is constructed from informal requirements, usually of poorly understood 
areas. Users exercise of the prototype to better understand and define requirements. The prototype must then be 
discarded, and system design is begun from the requirements. 

It is impoitant to avoid temptations to Iteep and build upon the prototype, because the very nature of rapid prototyp- 
ing causes generation of code that is inefficient, unsafe, unreliable, unmaintainable, etc. If, during development of 
the prototype, algorithms or designs are discovered that are particularly efficient, safe, reliable, maintainable, etc. 
they should be documented for consideration during the "rear design. 

Evolutionary Prototyping 

This prototyping model is also recommended for technologically difficult problems, but coven a larger area of the 
life cycle. It is hoped that the evolutionary prototyping efforts will help guide and speed the requirements definition, 
system design and implementation phases. 

A partial implementation of the system is constructed from partially known, well defined requirements, usually of 
well understood areas. Users exercise the prototype to better undersund and define remaining requirements. The 
prototype forms a set of baseline software which will be built upon to complete the deliverable versions. At this point, 
the model may transition to the Iterative Enhancement model. 

Development of an evolutionary prototype begins with well defined requirements. It takes longer than rapid 
prototyping, because good software engineering practices must be used to develop code that will eventually be pan of 
the working product. 

Iterative Enhanc -nent a.k,a. Incremental Development 

This model is recommended for applications that have a basic, well understood core set of functions. The model is 
characterized by many releases of new versions which add new functionality. Many market- penetration schemes will 
use this model to get a product into the marketplace and generating revenue, to pay for later enhancements. A rather 
complete set of requirements is known up front, and the releases of new functions are planned in advance; of course, 
the model is adaptable to new requirements and relies on user feedback to improve the product. 

Software Reuse 

This model may be used to cover the design portion of the waterfall or other similar model. It’s design paradigm 
relies mostly on the incorporation of previously proven designs and code into new software products. 

Automated Software Synthesis 

This is an advanced model that usually requires strict formulation of require me ms using a regular grammar specifica- 
tion language. This model offers the direct (and hopefully, automatic) transformation of requirements and/or high 
level design into code, either algorithmically or u»*ng a knowledge based rule set. It is hoped to eliminate the middle 
portions of the documentation set. centering around the detailed design. 

CASE tools currently exist that support this model to some degree. Typically, they will generate Ada package specs 
and the interface portions of package bodies from structure charts. 
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DEFINITIONS 


• SOFTWARE PROCESS MODEL (or LIFE CYCLE) 

v ’’The technical and management framework established for ap- 
plying tools, methods and people to the software task.” 

r Applies to the entire development cycle of the software, from 
concept to maintenance. 

• SOFTWARE METHODOLOGY 

v* Definition of a means for capturing requirements and design. 

^ Applies to one or more portions of the development cycle, usu- 
ally requirements analysis, specification or design. 



• TAILORING 

v* Selecting a subset of a Process Model or a Methodology for prac- 
tical application. 

• SOFTWARE QUALITY 

y The degree to which software matches customer/user needs. 
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INTRODUCTION 


+ MANY SOFTWARE PROCESS MODELS AND SOFTWARE 
METHODOLOGIES RECOMMEND TAILORING. 

t TAILORING IS USUALLY GUIDED BY PERSONAL EXPE- 
RIENCE, ABILLIY, AND TRADITION. 

* WE WILL DESCRIBE A METHOD FOR TAILORING. 



CUSTOMER/ 

USER NEEDS 

TAILORING TAILORING 
METHOD “P* RECOMMENDATIONS 



SUBSET OF INFORMATION PRODUCTS 



ALL INFORMATION PRODUCTS OF 
A SOFTWARE PROCESS MODEL 
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CHARACTERIZING CUSTOMER/USER NEEDS 

* WE WILL USE CONCEPTS FROM SOFTWARE QUALITY 
ASSURANCE (SQA) TO EXPLORE CUSTOMER NEEDS; 
v* What constitutes appropriate fitness for use of this software? 
p 0 What attributes must this software exhibit to be considered of 

high quality? 

v 0 Remember, software quality is more than ’’goodness”, it is a 
measure of how well the software matches the needs of the cus- 
tomer and user. 

* SQA SHOWS HOW TO OBJECTIFY A QUALITY RATING 
OF SOFTWARE, BY EVALUATING QUALITY FACTORS . 

p 0 Capture Quality Factors through Customer/User interviews. 

+ SQA SHOWS HOW TO TRANSLATE QUALITY FACTORS 
TO QUALITY CRITERIA . WHICH ARE MORE DIRECTLY RE- 
LATED TO SOFTWARE TESTABILITY. 
p 0 Derive Quality Criteria from Quality Factors 
p 0 Derive development techniques to enforce Quality Criteria 

- 3 Mark Arend 
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THE METHOD’S STEPS 

1 . PERFORM STANDARD INTERVIEWS AND DIALOGS BE- 
TWEEN DEVELOPER AND CUSTOMER/USER. 

2. GENERATE A PROFILE OF QUALITY FACTORS OF THE 
SOFTWARE TO BE DEVELOPED. 

3. TRANSLATE THIS QUALITY-NEEDS PROFILE INTO A 
SET OF QUALITY CRITERIA THAT MUST BE MET BY 
THE SOFTWARE. 

4. MAP THE CRITERIA TO A SET OF REQUIREMENT AND 
DEVELOPMENT TECHNIQUES. 

5. SELECT AND TAILOR THE INFORMATION PRODUCTS 
WHICH MATCH OR SUPPORT THOSE TECHNIQUES. 

| 6. SELECT AND TAILOR DESIGN METHODOLOGY(S) TO 

* PRODUCE THESE INFORMATION PRODUCTS. 
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THE METHOD’S STEPS 


1 

Fill out 
USER 

QUESTIONNAIRES 


Si £ 


i 


2 

Build 

QUALITY 

PROFILE 

(Factors) 


3,4 

Define 

QUALITY CRITERIA and 
SUPPORTING 
TECHNIQUES 


Correctness 

Efficiency 

Expandability 

Flexibility 

Integrity 

Interoperability 

Maintainability 

Manageability 

Ponability 

Usability 

Reliability 

Reusability 

Safety 

Survivability 

Verifiability 
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Tailor 

INFORMATION 

PRODUCTS 


Select 

DESIGN 

METHODOLOGY 


a 

tt 


Transformation 


TABLE OF 
CONTENTS 
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Translation 


Selection and 
Tailoring 
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Step 1 

PERFORM STANDARD INTERVIEWS AND DIALOGS BETWEEN DEVEL- 
OPER AND CUSTOMER/ USER 

» QUESTIONNAIRES DESIGNED TO PROBE THE USER’S 
NEEDS FOR QUALITY. 

t IMPORTANT TO DEFINE BOUNDARY OF SPECIFICA- 
TION, TO PREVENT OVER- OR UNDER-SPECIFICATION 
OF QUALITY NEEDS. 

* DEVELOPER WRITES QUESTIONNAIRES, USING A 
GREAT DEAL OF BOILERPLATE AND HELPS CUS- 
TOMER/USER THROUGH THE PROCESS. 

* EXAMPLE QUESTIONS 

|| v* How many users will want to use the system simultaneously? 

§> v* What level of user training is acceptable? 

* v* Will other computer systems rely on this one? 
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Step 2 

GENERATE A PROFILE OF QUALITY FACTORS OF THE SOFTWARE TO 

BE DEVELOPED 

» QUANTIFY RESPONSES TO USER QUESTIONNAIRES. 

t THE TAILORING METHOD DEFINES A TRANSFORMA- 
TION BETWEEN POSSIBLE RESPONSES AND QUALITY 
FACTORS. 

* THE TRANSFORMATION WILL APPLY WEIGHTED VAL- 
UES TO EACH RESPONSE, BASED UPON THE EFFECT 
THE ISSUE PROBED BY THE QUESTION HAS UPON ITS 
RELATED FACTOR(S). (Most questions will deal with decisions 
that influence several factors to varying degrees, even positively for 
some and at the same time negatively for others). 

t SINCE SOME FACTORS CONFLICT WITH OTHERS, A SEC- 
OND USER INTERVIEW MAY BE NECESSARY TO AM- 
PLIFY RELATIVE IMPORTANCE. Factor conflict may assist 
risk identification and management. 
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Step 3 

TRANSLATE THE QUALITY-NEEDS PROFILE INTO A SET OF QUALITY 

CRITERIA THAT MUST BE MET BY THE SOFTWARE 

* PRE-DEFINED GUIDELINES MAP FACTORS TO CRITE- 
RIA. 

t THIS TRANSLATION BRINGS US CLOSER TO WHAT 
QUALITY MEANS IN TERMS OF A SOFTWARE PROD- 
UCT, RATHER THAN IN TERMS OF THE USER. 

t SOME CRITERIA ALSO CONFLICT WITH ONE AN- 
OTHER. THIS TRANSLATION WILL ASSIGN RELATIVE 
WEIGHTS TO THE CRITERIA TO HELP REDUCE CON- 
FLICTS. 

t REMEMBER, CONFLICTS ARE NOT IMPOSSIBILITIES, 
THEY MERELY IDENTIFY AREAS REQUIRING EXTRA 
EFFORT AND EXCEPTIONAL TECHNIQUES - RISK MAN- 
AGEMENT. 
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Step 4 

MAP THE CRITERIA TO A SET OF REQUIREMENT AND DEVELOP- 
MENT TECHNIQUES 

+ TECHNIQUES OF DEVELOPMENT AND MANAGEMENT 

MAY BE USED TO ENSURE THE PRESENCE OF VARIOUS 
QUALITY CRITERIA. 

+ TYPES OF TECHNIQUES 
v* Product Recommendation 
p* Method Recommendation 
p* Standards Recommendation 
p 0 General Guidelines 

+ EXAMPLES 

p* Produce a traceability matrix to ensure Completeness. 
p 0 Use prototyping to ensure Usability, 
p* Adhere to interface standards to ensure Commonality, 
p - Separate critical & non-critical functions to ensure Safety Man- 
agement. 
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Step 5 

SELECT AND TAILOR THE INFORMATION PRODUCTS WHICH MATCH 

OR SUPPORT THE. TECHNIQUES 

» INFORMATION PRODUCTS ACT AS SPECIFIC GOALS 
WHICH FORCE US TO RECOGNIZE, FORMALIZE AND 
ADHERE TO TECHNIQUES TO SPECIFY, DESIGN AND 
IMPLEMENT SOFTWARE OF APPROPRIATE QUALITY. 

t INFORMATION PRODUCTS DOCUMENT REQUIRE- 
MENTS AND DESIGNS, PROVIDING FOR CONTINUITY 
OF DEVELOPMENT AND MAINTENANCE. 

t WE WISH TO SELECT THE APPROPRIATE SUBSET OF 
ALL POSSIBLE INFORMATION PRODUCTS. 

* THE TAILORING METHOD WILL DESCRIBE A UNI- 
VERSE OF INFORMATION PRODUCTS, AND WILL OF- 
FER A DIRECT TRANSLATION FROM QUALITY CRITE- 
RIA TO RECOMMENDED SUBSET OF THAT UNIVERSE. 
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Step 6 

SELECT AND TAILOR THE DESIGN METHODOLOGY WHICH PRO- 
DUCES THESE INFORMATION PRODUCTS 

» MANY METHODOLOGIES ARE AVAILABLE FOR SOFT- 
WARE REQUIREMENTS SPECIFICATION, SOFTWARE 
DESIGN AND IMPLEMENTATION. 

t THE TAILORING METHOD WILL DESCRIBE A UNI- 
VERSE OF METHODOLOGIES, AND WILL CATEGORIZE 
THEM BY THE INFORMATION PRODUCTS THEY PRO- 
DUCE. 

» THE MATCHUP BETWEEN INFORMATION PRODUCTS 
PRODUCED BY A METHODOLOGY AND THOSE RECOM- 
MENDED TO ACHIEVE THE QUALITY PROFILE FACILI- 
gj TATES THE SELECTION OF AN APPROPRIATE METH- 

1 1 ODOLOGY. 

r 

fit 
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CURRENT STATUS AND FUTURE WORK 

+ THIS PHASE OF THE RESEARCH EFFORT DEALT WITH 
DISCOVERY OF CONCEPTS AND ASSEMBLY OF DATA. 

+ AREAS ALREADY DEVELOPED TO SOME EXTENT 
^ Translation from Quality Profile to Quality Criteria 
^ List of Techniques sorted by Quality Criteria 

^ Universe of Information Products (enhanced NASA SMAP 
standard) 

^ Universe of Methodologies 

+ AREAS FOR DEVELOPMENT 
^ User Questionnaire boilerplates 
^ Response weighting scheme 

^ Transformation of weighted responses to Quality Profile 
^ List of Information Products sorted by Quality Criteria 
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